1. Field of the Invention
The present invention relates generally to a media transmission and reception method and system of a Push-to-Talk (PTT) over Cellular (PoC) system. In particular, the present invention relates to a method and system for transmitting and receiving media according to the importance of a media burst to be transmitted to a PoC user.
2. Description of the Related Art
The development of mobile communication and the spread of communication networks have contributed to various extra services and applications using cellular phones. At the same time, demand among cellular phone users for various extra services, such as a positioning service, a multimedia service, and a push-to-talk (PTT) service, is increasing. Among these extra services, the PTT service supports various supplementary functions such as an instant messenger function and a status display function, as well as supporting a group call and a voice call which are also provided by an existing radio or a Trunked Radio System (TRS).
Currently, standardization of a PTT-over-Cellular (PoC) service which employs the PTT function in a mobile communication network is actively being developed. One unique feature of the PoC service, which is distinguished from existing mobile communication services, is that a user can participate in a plurality of PoC sessions and can move among the PoC sessions to use a call service. A requirement that the user can move among the plurality of PoC sessions to use the call service is specified in the Open Mobile Alliance (OMA), which is a forum for specifying mobile communications services.
FIG. 1 is a schematic diagram of a conventional PoC service system. Referring to FIG. 1, a PoC client 102, which is a service requester installed in a PoC user terminal 100, is connected to a Session Initiation Protocol/Internet Protocol (SIP/IP) core network 120, which supports SIP and IP multimedia functions, via an access network 110.
The PoC client 102 resides in the PoC user terminal 100 to provide access to the PoC service. The PoC client 102 mainly serves in the side of a PoC user to initiate a PoC session, participate in a PoC session that is currently proceeding, and terminate a PoC session. In addition, the PoC client 102 acts to make and transfer a talk burst, support an instant personal alert, and perform authentication when accessing the PoC service. Hereinafter, unless otherwise stated, the PoC client 102 is assumed to be the same as a PTT service subscriber.
The SIP/IP core network 120 is connected to a PoC server 150, a PoC Extensible Markup Language Document Management Server (XDMS) 140, and a PoC box 180, in order to support the PoC service.
The PoC server 150 has a controlling PoC function for maintaining and managing a PoC session, or a participating PoC function for participating in a PoC session established for a one-to-one PoC call or a one-to-many PoC call.
A function of the PoC server 150 is classified into a controlling PoC function (CF) for generally maintaining and managing a PoC session and a participating PoC function (PF) for maintaining and managing each PoC session, which will be described in more detail with reference to Tables 1 and 2.
TABLE 1Controlling PoC Function (CF) provides centralized PoC session handlingProvides the centralized Media distributionProvides the centralized Talk Burst Arbitration functionalityincluding talker identificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides the participants informationCollects and provides centralized media quality informationProvides centralized changing reportMay provide transcoding between different codecsSupport Talk Burst Control Protocol Negotiation
As shown in Table 1, the CF serves to generally manage a PoC session among functions of the PoC server 150. The PoC server 150 receives requests for a floor (right-to-talk) from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The PoC server 150 also distributes a talk burst from a specific PoC client to all PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PF manages a PoC session between the CF and each PoC client. In particular, the PF acts to relay the floor between the PoC client and the CF when the PoC client requests the floor or when the CF gives the floor to the PoC client. In addition, the PF serves to relay media between the CF and the PoC client, provide transcoding between different codecs, and provide a filtering function for filtering one of two PoC sessions chosen by a user when there is simultaneous talking in two simultaneous PoC sessions.
TABLE 2Participating PoC Function (PF) provides PoC session handlingMay provide the Media relay function between PoC Client andControlling PoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function betweenPoC Client and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc., on behalf of the represented PoC ClientProvides policy enforcement for incoming PoC session(e.g. access control, incoming PoC session barring,availability status, etc.)May collect and provide media quality informationProvides the participant charging reportsMay provide filtering of the media streams in the case of simultaneoussessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC Client
An aggregation proxy server 160 acts to collect requests of all entities using an XML Configuration Access Protocol (XCAP) in the PoC service system and transfer the requests to corresponding entities.
In order to use a PoC call service, the PoC user registers his/her PoC address in the SIP/IP core network 120. The SIP/IP core network 120 stores information regarding the PoC user at the request of the PoC user. Thus, when another PoC user tries to request a group PoC call, the PoC user registers his/her information in the SIP/IP core network 120 in advance, as described above, and requests the group PoC call to his/her SIP/IP core network 120 by using group identification information transmitted from the PoC XDMS 140. The SIP/IP core network 120 performs address determination and domain location determination using information on the call requesting PoC user, and then transfers a PoC call request to a home PoC server with which the call requesting PoC user is registered. In regard to the PoC call request, the PoC server 150 prepares for establishment of a PoC session, obtains each user's information from the PoC XDMS 140, and then transfers a PoC call request signal to a corresponding SIP/IP core network 120. Here, in the case of a PoC call request to users within an Intradomain, the PoC server 150 performs both the CF and PF functions. The PoC server 150, which manages a call-requested PoC user, requests a PoC call to the PoC user after the SIP/IP core network 120 performs the location determination procedure, by using information on the PoC user that is transmitted to the PoC server 150. If the call-requested PoC user transmits an OK response to the call requesting PoC user, a PoC call is connected. When a PoC call is not connected due to the state of another PoC user regardless of a PoC call request of a PoC user, the PoC user can store his or her voice or media desired to transmit, using the PoC box 180.
As described above, the PF can manage simultaneous PoC sessions. In the simultaneous PoC sessions, a PoC client cannot simultaneously receive media transmitted from a plurality of sessions. That is, only media related to a single session can be transmitted to a PoC user for a transport time. In general, a PoC server keeps a first-in first-out basis regardless of media transmitted from any session. The PoC server removes other media received while media is being transferred. In this case, the PF may filter media which the PoC user must receive. In order to prevent this case, a media receiving PoC user can set a primary or locking-in session. In the case of a primary or locking-in session, even if other media is being transferred, media related to the primary or locking-in session is transferred first of all.
FIG. 2 is a signaling diagram of a process of transmitting and receiving media in conventional simultaneous PoC sessions. In FIG. 2, it is assumed that a PoC client B has set a PoC session controlled by a PoC server X1 as a primary or locking-in session in a PF in advance.
The PoC client B has three PoC sessions connected to each other by means of a Participating PoC server B (PF). Servers controlling each PoC session are the PoC server X1 (CF1), a PoC server X2 (CF2), and a PoC server X3 (CF3). Each PoC server transmits media to the Participating PoC server B (PF).
It is assumed that the PoC server X3 (CF3) transmits media in step 200, the PoC server X1 (CF1) transmits media in step 202, and the PoC server X2 (CF2) transmits media in step 204. In a general case, i.e. in the case where all the PoC sessions have the same priority, the first transmitted media X3 must be transmitted to the PoC client B. However, since the PoC session controlled by the PoC server X1 (CF1) is set as the primary or locking-in session by a PoC user, the media of the PoC session controlled by the PoC server X1 (CF1) is filtered in step 206. Even though the media X1 has been transmitted to the Participating PoC server B (PF) after the media X3, the Participating PoC server (PF) transmits the media X1 to the PoC user (PoC client B) in step 208, according to the filtering operation of step 206.
In general, in order for a PoC user to transmit a media burst, a message for requesting a media transmission right (Media Burst Control Protocol (MBCP) Request message), a message for informing PoC users participating in a PoC session of who transmits media (MBCP Taken message), and a message for permitting media transmission (MBCP Granted message) are necessary. If a PoC client transmits an MBCP Request message to a PoC server, the PoC server determines whether media transmission is limited, and transmits an MBCP Granted message to the PoC client. Only the PoC user who has received the MBCP Granted message can talk.
The MBCP Request message has a message format illustrated in FIG. 3.
Referring to FIG. 3, the first 2-bit field is for a Real-time Transport Protocol (RTP) version. In the case of the present invention, the RTP version is 2. The second 1-bit field is for a padding bit. It can be seen that, if the padding bit is given, one or two padding octets that are not contained in a payload are added. The third 5-bit field indicates a subtype. It can be seen by referring, to an OMA PoC User Plane specification, which function of a Time Burst Control Protocol (TBCP) a Real-time Transport Control Protocol Application (RTCP APP) packet performs using the subtype. For example, in the specification that is currently drafted in the OMA, the subtype has values defined as 00000 for a TBCP Talk Burst Request message, and as 00001 for a TBCP Talk Burst Granted message. Since 16 TBCP Talk Burst Control messages are defined as of now, the subtype values are defined up to 01111. The remaining 16 values are reserved for the TBCP Talk Burst Control messages to be newly created in the future. The fourth 1-byte field is for a Packet Type (PT), and is shown as PT=204, which indicates that this message is an RTCP APP packet. The fifth 2-byte field is for a length field. If a value of 2 is used in the length field, this indicates that the message has two 4-byte octets. If the value is followed by a payload, this indicates a length of the payload, i.e. how many 4-byte octets exist in the payload. The sixth 4-byte field is a Synchronization SouRCe (SSRC) field. This field contains a synchronization source to discriminate who sent the RTCP APP message. The seventh 4-byte field is expressed by American Standard Code for Information Interchange (ASCII), which has the function of discriminating a PoC version according to the OMA PoC specification.
The eighth 1-byte option ID field indicates the priority if a value of the option ID is 1 or an MBCP Request transport time stamp if the value of the option ID is 2, when a PoC user transmits media.
As described above, in the conventional simultaneous PoC sessions, a PoC client cannot simultaneously receive media transmitted from a plurality of sessions. Only media related to a single session can be transmitted to a PoC user for a transport time. In general, first input media is output first regardless of media transmitted from any session. Other media received while media is being transferred is removed. In this case, the Participating PoC server (PF) may filter media which the PoC user must receive. In order to prevent this case, a media receiving PoC user can set a primary or locking-in session. In the case of a primary or locking-in session, even if other media is being transferred, media related to the primary or locking-in session is transferred first of all.
As described above, according to the request of a media receiving PoC user, it can be set so that media transferred from a specific session can be received without filtering in a PoC server. That is, in the conventional simultaneous PoC sessions, while media transmission can be determined by a selection of a media receiving PoC user, there is no method used by a media sending PoC user to set to transfer media corresponding to an important message without filtering. Thus, when the media sending PoC user transmits media containing an important message, the message may not be transferred. Accordingly, when a PoC user transmits important media, it is necessary to inform a target PoC user of the importance of the media to be transmitted, and a method of surely transmitting the important media without filtering is required.